proposal : better_craigslist #1
Conversation
|
Unfortunately, I do not understand how does it contribute to Plonk3/Circom in an innovative or experimentation way. One thing I can see is you mentioned writing ZkEmail circuits using Circom, but is it different from something which is already out there? eg. https://github.com/zkemail already exists. |
|
Our implementation will stretch the capabilities of Plonky3 and Circom: Our project aims to push the boundaries of Plonky3 and CIRCOM in practical, high-stakes applications. While we're building on existing ZKEmail concepts, we're innovating in several key areas: a) We're developing specialized Plonky3 circuits optimized for high-throughput, low-latency email verification in a marketplace context. This will stress-test Plonky3's capabilities in ways not previously explored. Innovative aspects of ZKEmail circuits: While ZKEmail circuits exist, our implementation differs in several important ways: a) We're adapting these circuits for a new use case (secure marketplaces), which presents unique challenges and opportunities for optimization. |
|
Would really appreciate your comments here as well. |
Hi @YashBit, I think your proposal is much more focus on application side and apply zkEmail to actual product in this case it's a C2C market (I hope I understand it correct). I'd prefer that you just focus on improving zkEmail or adding new feature into it then the proposal may fit to the program's requirement. The idea is interesting but I have concern about data integrity and censorship. Thanks, |
|
@chiro-hiro @johnsoncarl Updated. |
High level implementation steps
|
@chiro-hiro Would deeply appreciate your comments on the updated proposal. |
|
Gonna check now 🤗 |
|
@chiro-hiro Please can we connect on Telegram. |
applications/better_craigslist.md
Outdated
| The primary goal is to extend zkEmail's functionality by implementing the following use cases: | ||
|
|
||
| - Enhanced data integrity verification for email attachments using Plonky3 | ||
| - Experiment with following attachment formats: PDF, DOCX, PNG, JPEG |
There was a problem hiding this comment.
I think attachment can be treated as binary data and it isn't depend on file extension. The most hard part is proving the attachment is a part of email.
Why do we need to generate proof for every attachment instead of create a proof for the whole email if we don't receive any benefit from it?.
There was a problem hiding this comment.
The idea is actually to have a circuit that decodes the attachment and then can perform some operation in it. For this we will start with the base case for PDF, and DOCX as we can then use zk-regex to prove that the attachment had some statement that we want to prove. It is something that is also pointed out on the repo as a Research Idea (Attachment Parsing Circuit) and this opens a lot of possibilities. Is also pointed out as having some performance bottlenecks so we want to try with plonky3 and do some research on how we can remove this performance issue
There was a problem hiding this comment.
The attachment is actually binary data on the email body, it is encoded into base64
applications/better_craigslist.md
Outdated
| This project aims to enhance zkEmail by developing new features and improvements using Plonky3, specifically tailored for decentralized systems with a focus on C2C marketplaces. We will expand zkEmail's capabilities to address data integrity, censorship resistance, and privacy, while pushing the boundaries of Plonky3's application in practical scenarios. | ||
|
|
||
| Core Idea: | ||
| The primary goal is to extend zkEmail's functionality by implementing the following use cases: |
There was a problem hiding this comment.
| The primary goal is to extend zkEmail's functionality by implementing the following use cases: | |
| The primary goal is to extend zkEmail's functionality by implementing the following features: |
applications/better_craigslist.md
Outdated
| - Chain the proofs to generate a final proof and verifier | ||
|
|
||
| - Privacy-preserving reputation systems based on email interactions using Plonky3's lookup arguments | ||
| - Gather interaction data (data in email interactions such as the number of emails sent/received, response times, content length, etc.). |
There was a problem hiding this comment.
Regarding to gather interaction data, we only able to gather it as long as we have access to the mail server, the proposal is missing the clarification for this in reputation feature.
Will reputation calculation algorithm be available publicly? If it available publicly how can we make sure adversaries won't able to trick the algorithm?
There was a problem hiding this comment.
For the reputation system, we just removed it from the proposal as after some research we realised the work timeframe would be unrealistic for having it in this same proposal. Therefore, we chose to take it out and we intend to submit as a proposal in a later round, though we have the algorithm hashed out.
With this removed we can focus more on the usage of plonky3 to implement this new feature for it and also improve some of the circuits that are in circom.
|
I've just added more comments, I'm prefer to have a section to provide more detail of your solution. Right now, everything is described in common term, so I think it is very difficult for mentors to evaluate feasibility of the project. My Telegram is: chiro8x |
|
@chiro-hiro Made the required changes. |
|
Merging this PR For application review |
|
@chiro-hiro Hi, I hope you liked all our answers. Thank you so much for putting in the energy to guide our team. |
Proposal for ZK Bankai